Skip to content

Add sensor firmware upload API support #93340

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

avisconti
Copy link
Contributor

Add sensor API to perform a "firmware upload". This new driver API is then used as a vehicle to upload a ISPU configuration into lsm6dso16is sensor (see ST ISPU for more details).

This PR is also changing the lsm6dso16is driver and modifying the x_nucleo_iks4a1 shield sample.

@avisconti avisconti added this to the v4.3.0 milestone Jul 18, 2025
@avisconti avisconti added Enhancement Changes/Updates/Additions to existing features area: Drivers area: Sensors Sensors area: Samples Samples area: API Changes to public APIs DNM This PR should not be merged (Do Not Merge) labels Jul 18, 2025
@zephyrbot zephyrbot added the area: Shields Shields (add-on boards) label Jul 18, 2025
Copy link

github-actions bot commented Jul 18, 2025

The following west manifest projects have changed revision in this Pull Request:

Name Old Revision New Revision Diff

All manifest checks OK

Note: This message is automatically posted and updated by the Manifest GitHub Action.

@github-actions github-actions bot added manifest manifest-hal_st DNM (manifest) This PR should not be merged (controlled by action-manifest) labels Jul 18, 2025
@avisconti avisconti force-pushed the add-ispu-fw-upload branch 2 times, most recently from 2b12ac2 to 504006c Compare July 18, 2025 16:06
Copy link
Contributor

@thedjnK thedjnK left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is using blobs right, where it is using the zephyr blobs feature? https://docs.zephyrproject.org/latest/contribute/bin_blobs.html

@avisconti
Copy link
Contributor Author

This is using blobs right, where it is using the zephyr blobs feature? https://docs.zephyrproject.org/latest/contribute/bin_blobs.html

Well, no, it it is not using blobs. The purpose of this PR is to introduce a new sensor API to upload a "firmware" (please note the quotes) to a sensor. In ST case this is just a register configuration in a .h file, which will be visible in hal_st module (but not as binary blobs). For other sensor drivers which decide to use the fw_upload API, it might be implemented as binary blobs.
Am I missing something?

@thedjnK
Copy link
Contributor

thedjnK commented Jul 22, 2025

This is using blobs right, where it is using the zephyr blobs feature? https://docs.zephyrproject.org/latest/contribute/bin_blobs.html

Well, no, it it is not using blobs. The purpose of this PR is to introduce a new sensor API to upload a "firmware" (please note the quotes) to a sensor. In ST case this is just a register configuration in a .h file, which will be visible in hal_st module (but not as binary blobs). For other sensor drivers which decide to use the fw_upload API, it might be implemented as binary blobs. Am I missing something?

https://github.com/STMicroelectronics/st-mems-ispu/tree/master/host_firmware/nucleo_ispu_stedgeai_validate/binary this is binary

https://github.com/STMicroelectronics/st-mems-machine-learning-core/blob/main/examples/6d_position_recognition/iis2dulpx/iis2dulpx_six_d_position.h#L165 and https://github.com/STMicroelectronics/st-mems-finite-state-machine/blob/main/examples/flip_down_detection/lsm6dsr/lsm6dsr_flip_down.h#L161 what are these if not binary blobs?

@avisconti
Copy link
Contributor Author

This is using blobs right, where it is using the zephyr blobs feature? https://docs.zephyrproject.org/latest/contribute/bin_blobs.html

Well, no, it it is not using blobs. The purpose of this PR is to introduce a new sensor API to upload a "firmware" (please note the quotes) to a sensor. In ST case this is just a register configuration in a .h file, which will be visible in hal_st module (but not as binary blobs). For other sensor drivers which decide to use the fw_upload API, it might be implemented as binary blobs. Am I missing something?

https://github.com/STMicroelectronics/st-mems-ispu/tree/master/host_firmware/nucleo_ispu_stedgeai_validate/binary this is binary

host_firmware is part of the repo but is not relevant inside zephyr. Would that be an issue anyway?

https://github.com/STMicroelectronics/st-mems-machine-learning-core/blob/main/examples/6d_position_recognition/iis2dulpx/iis2dulpx_six_d_position.h#L165 and https://github.com/STMicroelectronics/st-mems-finite-state-machine/blob/main/examples/flip_down_detection/lsm6dsr/lsm6dsr_flip_down.h#L161 what are these if not binary blobs?

OK, these two examples are in fact what it has to be uploaded.

Add Firmware upload API

Signed-off-by: Armando Visconti <[email protected]>
@thedjnK
Copy link
Contributor

thedjnK commented Jul 24, 2025

This is using blobs right, where it is using the zephyr blobs feature? https://docs.zephyrproject.org/latest/contribute/bin_blobs.html

Well, no, it it is not using blobs. The purpose of this PR is to introduce a new sensor API to upload a "firmware" (please note the quotes) to a sensor. In ST case this is just a register configuration in a .h file, which will be visible in hal_st module (but not as binary blobs). For other sensor drivers which decide to use the fw_upload API, it might be implemented as binary blobs. Am I missing something?

https://github.com/STMicroelectronics/st-mems-ispu/tree/master/host_firmware/nucleo_ispu_stedgeai_validate/binary this is binary

host_firmware is part of the repo but is not relevant inside zephyr. Would that be an issue anyway?

It can't be hosted on a zephyr repo

https://github.com/STMicroelectronics/st-mems-machine-learning-core/blob/main/examples/6d_position_recognition/iis2dulpx/iis2dulpx_six_d_position.h#L165 and https://github.com/STMicroelectronics/st-mems-finite-state-machine/blob/main/examples/flip_down_detection/lsm6dsr/lsm6dsr_flip_down.h#L161 what are these if not binary blobs?

OK, these two examples are in fact what it has to be uploaded.

But they're binary blobs right? Like I can't take them and use them on some other device?

Add support to Intelligent Sensor Processing Unit (ISPU).
It requires to upload a ISPU configuration using the sensor_upload_fw()
API and to handle requests through the SENSOR_CHAN_ST_ISPU proprietary
channel.

Signed-off-by: Armando Visconti <[email protected]>
@avisconti avisconti force-pushed the add-ispu-fw-upload branch from 504006c to d6c42fc Compare July 25, 2025 13:45
@github-actions github-actions bot removed manifest manifest-hal_st DNM (manifest) This PR should not be merged (controlled by action-manifest) labels Jul 25, 2025
@avisconti
Copy link
Contributor Author

This is using blobs right, where it is using the zephyr blobs feature? https://docs.zephyrproject.org/latest/contribute/bin_blobs.html

Well, no, it it is not using blobs. The purpose of this PR is to introduce a new sensor API to upload a "firmware" (please note the quotes) to a sensor. In ST case this is just a register configuration in a .h file, which will be visible in hal_st module (but not as binary blobs). For other sensor drivers which decide to use the fw_upload API, it might be implemented as binary blobs. Am I missing something?

https://github.com/STMicroelectronics/st-mems-ispu/tree/master/host_firmware/nucleo_ispu_stedgeai_validate/binary this is binary

host_firmware is part of the repo but is not relevant inside zephyr. Would that be an issue anyway?

It can't be hosted on a zephyr repo

https://github.com/STMicroelectronics/st-mems-machine-learning-core/blob/main/examples/6d_position_recognition/iis2dulpx/iis2dulpx_six_d_position.h#L165 and https://github.com/STMicroelectronics/st-mems-finite-state-machine/blob/main/examples/flip_down_detection/lsm6dsr/lsm6dsr_flip_down.h#L161 what are these if not binary blobs?

OK, these two examples are in fact what it has to be uploaded.

But they're binary blobs right? Like I can't take them and use them on some other device?

I'm reconsidering all this part.

@avisconti
Copy link
Contributor Author

Marked as DNM because the lsm6dso16is driver should be ported to use read_and_decode APIs. At this point, the ISPU embedded core data will be not passed using fetch and get.

Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: API Changes to public APIs area: Drivers area: Samples Samples area: Sensors Sensors area: Shields Shields (add-on boards) DNM This PR should not be merged (Do Not Merge) Enhancement Changes/Updates/Additions to existing features
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants